1. Field of the Invention
The present invention relates to presence communication systems, and more particularly, to a presence communication system for carrying out presence to check the status of a target of communication before the start of communication.
2. Description of the Related Art
In recent years, development of ubiquitous network has been rapidly advanced which network enables a user, wherever he/she may be, to locate a recipient with whom the user wishes to communicate, in an environment where communication is achievable, and to establish an end-to-end logical connection for initiating communication.
In ubiquitous network environments, the recipient may possibly be absent or may not have access to fulltime connection, and accordingly, allowing the user to know in advance whether the recipient is currently available or not is very effective in facilitating communication.
This function has been standardized as “presence” since it represents the presence of a recipient. With the presence function, the user is notified of the presence and status of the recipient, enabling the user to select a suitable communication means matching the status of the recipient and to initiate communication.
The presence technology enabling the user to check the status of the recipient before communication is defined in RFC (Request For Comment) 2778 of the IETF (Internet Engineering Task Force) and is currently attracting attention as a key technology in future ubiquitous networks.
FIG. 36 depicts an overview of a presence service system. The presence service system 100 is comprised mainly of a presence server 110, a presentity 120 and a watcher 130, and presence information is requested and provided via the presence server 100. The presentity 120 is an entity that presents presence information, and the watcher 130 is an entity that views the presence information (in general, the presentity is a user and the watcher is a service provider).
Basically, information flows in the manner described below. First, the watcher 130 sends a request for presence information to the presence server 110. The presence server 110 forwards the presence information request to the presentity 120, which then sends its presence information (e.g., user status indicating whether the user is currently available or not) as a reply.
The watcher 130 recognizes the status of the presentity 120 from the presence information received via the presence server 110 and, if the status permits, provides service to the presentity 120.
As conventional techniques related to presence service, a technique has been proposed wherein the presence information of a certain presentity is automatically updated using, as a trigger, change in the presence information of some other presentity (e.g., Japanese Unexamined Patent Publication No. 2004-228833 (paragraph nos. [0020] to [0046], FIG. 1)).
In the presence service according to RFC 2778, the presentity 120 provides presence information to the presence server 110 by using its own URI (Uniform Resource Identifier), and the watcher 130 specifies the URI of the presentity 120 when acquiring the presence information from the presence server 110. This enables the watcher 130 to recognize the status of the presentity 120, and the watcher 130 subsequently provides service to the presentity 120. The conventional mechanism is, however, associated with the problem that an enormous number of messages must be exchanged in a large-scale system.
FIG. 37 illustrates the problem with the conventional presence service according to RFC 2778. Let us consider a system involving 100 presentities and 100 watchers. If each of the 100 watchers 130-1 to 130-100 collects presence information from the 100 presentities 120-1 to 120-100, for example, each of the 100 presentities 120-1 to 120-100 sends presence information to the presence server 110 to be distributed to the 100 watchers 130-1 to 130-100, requiring 10,000 (=100×100) notification messages (presence information) (each presentity sends the same presence information to the 100 watchers and there are 100 presentities; therefore, 100×100).
Similarly, the presence server 110 sends the presence information to the watchers 130-1 to 130-100 by using 10,000 (=100×100) notification messages. Consequently, a total of 20,000 notification messages are required to deliver the presence information.
Thus, in the conventional presence service according to RFC 2778, the number of notification messages increases drastically with increase in the number of presentities and watchers, giving rise to a problem that the communication quality lowers.